The present application is related to the following commonly assigned applications filed on the same date as the present application, each of which is herein incorporated by reference:
U.S. Ser. No. 09/038,024, now U.S. Pat. No. 6,106,569, by Kathryn Bohrer et al., entitled xe2x80x9cA Method of Developing a Software System Using Object Oriented Technologyxe2x80x9d;
U.S. Ser. No. 09/038,352, filed Mar. 11, 1998, by Brent Carlson et al., entitled xe2x80x9cA Method of Using Decoupled Chain of Responsibilityxe2x80x9d;
U.S. Ser. No. 09/038,351, now U.S. Pat. No. 6,070,152, by James Carey et al., entitled xe2x80x9cFramework for Business Applications Providing Financial Integrationxe2x80x9d;
U.S. Ser. No. 09/038,349, now U.S. Pat. No. 6,092,075, by James Carey et al., entitled xe2x80x9cFramework for Business Applications Using Cached Aggregate and Specification Keyxe2x80x9d;
U.S. Ser. No. 09/038,025, now U.S. Pat. No. 6,134,706, by James Carey et al., entitled xe2x80x9cSoftware Business Objects in a Multi-level Organizational Structurexe2x80x9d; and
U.S. Ser. No. 09/041,114 by Brent Carlson et al., entitled xe2x80x9cMethod of Error Handling in a Frameworkxe2x80x9d, now issued as U.S. Pat. No. 6,052,525.
The present invention relates to a method of developing a software system using Object Oriented Technology and frameworks.
In order to maintain or enlarge their competitiveness, enterprises of almost every type of business all over the world have to rework and bring up to date their information technology to meet customer""s requirements and thus to be successful in the market. But keeping an information system based on traditionally developed software up to date is at least an expensive undertaking, and in many cases it is an unsolvable problem. Object Oriented Technology or simply Object Technology, often abbreviated xe2x80x9cOOTxe2x80x9d or simply xe2x80x9cOTxe2x80x9d, has the technical potential to overcome the problems associated with development, maintenance, and extension of software applications within a company""s information system and to provide interoperability and adaptability across multiple applications and hardware platforms.
Object Oriented Technology describes a method for the development of operating software as well as application software for a computer system. Contrary to the traditional, non object oriented ways of developing software, Object Oriented Technology comprises and uses preengineered xe2x80x9cmethodsxe2x80x9d and xe2x80x9cobjectsxe2x80x9d for the development of software, comparable to tools and parts for the development of an automobile.
Similar to the development of an automobile, wherein not each required screw is developed individually, but standardized screws are used which can be individually adapted by shortening to the required length, within the development of software, Object Oriented Technology provides a xe2x80x9cclassxe2x80x9d as a kind of software template from which individual xe2x80x9cobjectsxe2x80x9d can be instantiated. These classes are usually stored in a software library or a so called xe2x80x9cclass libraryxe2x80x9d. A class library is simply a collection of several classes stored together in a special filing format called a library.
In Object Oriented Technology an xe2x80x9cobjectxe2x80x9d is a self-contained piece of software consisting of related data and procedures. Data means information or space in a computer program information can be stored, e.g. a name or an inventory part number. Procedures are parts of a program that cause the computer to actually do something, e.g. the parts of a program which perform calculations or the part of a program that stores something on a computer disk. In Object Oriented Technology, an object""s procedures are called xe2x80x9cmethodsxe2x80x9d.
The concept of an object being a self-contained piece of software having data and procedures inside itself is a new way of developing software. In non object oriented software, most of the data for an entire program is often grouped together near the beginning of the program, and the procedures then follow this common pool of data. This conventional method worked okay for smaller programs, but as soon as a piece of software started to grow and become somewhat complex, it become increasingly difficult to figure out which procedures were using which data. This made it quite difficult and expensive to debug or change traditional software programs.
In Object Oriented Technology it is generally easier to debug, maintain, and enhance object oriented software. The three most popular object oriented programming languages are probably xe2x80x9cC++xe2x80x9d, xe2x80x9cJAVAxe2x80x9d, and xe2x80x9cSmalltalkxe2x80x9d. The concept that both data and methods are contained inside an object is called xe2x80x9cencapsulationxe2x80x9d. Part of the concept of encapsulation is that an object has a predictable way of communicating with other objects, a so called predictable xe2x80x9cinterfacexe2x80x9d or sometimes also called the method contract.
Provided that interface will not be changed, the code or methods inside the object can be changed without disrupting other objects"" ability to interact with that object. For example, a TAX CALCULATION object would have a predictable interface for use by PAYCHECK objects. Provided that interface will not be changed, the detailed program code inside the TAX CALCULATION object could be changed whenever the tax laws changed, and no other objects in the payroll system would have to know anything about such changes.
In Object Oriented Technology the term xe2x80x9cinheritancexe2x80x9d is used to communicate the concept that one inherit part of its behavior and data from another object, e.g. since an employee is a type of person, an EMPLOYEE object might inherit the characteristics of a PERSON object, such as having name, birth date, and address data, as well as an EMPLOYEE object might inherit methods for updating and displaying these data.
Even if an object inherits some of its characteristics from other objects, that object can, and usually would, also have its own non-inherited characteristics, e.g. whereas a PERSON object would have an inheritable method to display a person""s address, a PERSON object would probably not have a method for displaying paycheck history, since not all persons get paychecks. Because an EMPLOYEE object could not inherit this method from a PERSON object, an EMPLOYEE object would have to define its own method for displaying paycheck history.
Although Object Oriented Technology clearly seems to be the most sophisticated way for the development, maintenance, and extension of software applications, many companies developing software applications are concerned about the cost and risks involved with the rework of existing applications and with the construction of new applications using Object Oriented Technology. For those software application developers, a technical foundation for software applications has to be built as a tool using Object Oriented Technology as the basis, allowing each developer to develop highly unique software products. This technical foundation is formed by frameworks comprising the basic application structure which software application developers previously had to develop by themselves.
In Object Oriented Technology the term xe2x80x9cframeworkxe2x80x9d is used to describe a reusable set or collection of classes which work together to provide a commonly needed piece of functionality not provided by any of the individual classes inside the framework. Thus a framework defines a specific way in which multiple objects can be used together to perform one or more task which no single object performs. In other words, a framework is a reusable, predefined and preengineered bundle of several objects which address a recurring programming problem.
Frameworks provide a way of capturing a reusable relationship between objects, so that those objects do not have to be reassembled in that same relationship every time they are needed. Frameworks provide a way of grouping multiple objects together to perform some function which should not have to be thought through each time at the underlying object level. For example, a PRINT framework would consist of all the objects necessary for a programmer to easily print something on any printer, and would probably include objects for printer selection, spooling to disk or error detection as xe2x80x9cout of paperxe2x80x9d. Frameworks can be regarded as a group of software objects which contain a technical foundation for a software application. For example in the business field of Financial, Logistic and Distribution or Production. Although a framework represents a skeleton of a software application, usually a framework is not an executable software program.
By providing frameworks as the technical foundation for developing software applications, the following problems have to be addressed:
Applications have to support all hardware platforms and related software operating systems relevant on the market. Applications have to fulfill the requirements related to client/server configurations including the requirement for graphical user interfaces and windowing techniques. Also, applications have to offer internet compatibility and access on demand. Furthermore, applications have to provide integrated solutions with respect to installed software.
Known from the prior art, see e.g. E. GAMMA et al: xe2x80x9cDesign Patterns: elements of reusable object-oriented softwarexe2x80x9d, Addison-Wesley, 1995, ISBN 0-201-63361-2, is a collection of useful patterns for building up a software system using Object Oriented Technology and frameworks.
Using a common framework will cause all persistent objects to be stored in the same container. For a small system using a single server this may be a good solution. But for a larger system this cannot be used. In particular if more than one server is deployed, there is a need for a way to allocate objects on to different servers. This is necessary to distribute work between servers. Also the servers may be located in different physical locations.
Allocation of objects across different containers is particularly of interest, when moving all objects of a certain class does not make sense. The main reasons for distributing instances of a given class across several containers are:
The usage of objects are distributed across clients and the clients have different communication speed or reliability in the links to the different servers.
The instances need be stored using different storage mechanisms, thus requiring different containers. This would typically be an issue where similar objects are mapped to more than one legacy database.
During the remaining portion of the application the following terminology will be used:
Container
A container within the present application is a logical unit of storage for persistent objects. A container resides on a single server. All objects in a container are stored by the same storage mechanism, e.g. if you want some objects to be stored using a Posix persistence, some in DB/2 for NT and some in Oracle, you will need at least three containers. You may have more than one for the same storage mechanism.
Controller
A controller is an object that owns a collection of other objects. The other objects are of the same class (or at least of the same superclass). A controller appears in a similar role as the master data tables in a traditional system, e.g. there may be a Currency controller or a Business Partner controller. All containers within this application are implemented to hold one or several collections internally, but presents an interface externally that hides the complexity of this implementation detail. To the client of the controller it appears as the controller is the single xe2x80x9ccollectionxe2x80x9d. There are several objects that are not owned by a controller, but by another business object. For the rest of this application an object owning a collection of other objects can be considered as a controller, even if the class is not named a controller.
Ownership
In general, objects within the present application may be owned or independent. Objects that are of a subclass of Dependent are always owned. Entities, i.e. objects that are subclasses of Entity, may be either owned or independent. The domain frameworks, i.e. Common Business Objects, General Ledger etc., are designed so that all Entities except one are owned. This single object that is not owned is the company controller, that is the root of the ownership hierarchy.
Location Object
When a new object is created the client code calls a static method on the Factory Class associated with the class of which the new object is going to be an instance of. On the creation method the client code will pass a location object (explicitly or using the owner). The new object will be created in the container where the location object is stored. The location parameter can either be an existing business object, or it can be a specific Container object specifically representing a certain Container. The domain frameworks always pass the owner as the location object.
This leads to the conclusion that all objects are located in the same Container as the Company controller.
Collection Types
There are different types of collections. Controllers may be implemented by either one of the collection types, but typically the ones with map behavior is used. In the following it is important to understand the difference between Extents and the other collection types in terms of the location aspect.
Within the accompanying figures, representation standards for classes, objects, relationships etc. are used at least partly according to Grady Booch: xe2x80x9cObject-Oriented Analysis and Design with Applicationsxe2x80x9d, second edition, The Benjamin/Cummings Publishing Company, Ind., Redwood City, Calif., USA.
It is an object of the present invention to provide a technical foundation for the development of software applications using Object Oriented Technology which overcomes the above discussed problems.
It is a further object of the present invention to provide a method of locating objects in different containers, particularly to address the allocation of objects across different containers when moving all objects of a certain class does not make sense.
The present invention solves this problem with a method of locating software objects as laid down in enclosed independent claim. Particular embodiments of the present invention are presented in the respective dependent claims.
In particular, the problem is solved by a method of locating software objects in a software system, e.g. for a business application, across logical storage units, said method is characterized in that said locating of said objects is performed according to a usage of said objects.
Distributing objects across logical storage units, e.g. across containers, according to usage rather than by class allows for better performance, increased security, better availability and lower cost.
Clients may be located close to a server. In this scenario it is useful to locate objects according to how frequently they are used by different clients. Typically there will be a pattern to this. If the object is located on the server that the premier clients has the fastest communication links to, one typically gets the best performance from the system.
In a preferred embodiment of the present invention said locating is controlled by the facts whether
there are one or several of attributes passed on creation of a new object that can be used to determine a location of said new object, and whether
there is a controller for said object implemented with an extent collection.
The impact of a change to one of these attributes after the create has to be considered, i.e. the questions: does the object has to move, can this be performed now, etc.
Extents and its elements are always in the same container.
No changes are required to the client code that performs the creation.
In certain cases the relevant location object is available in the client code even if it is not passed on the creation signature. In other cases the input to the client code, typically the GUI (Graphical User Interface), must be changed to indicate the location object. Also the client code must be changed to use the new signature.
Although there is no need to class replace the controller to use multiple collections, one for each container, it may be wise to do so anyway, in particular if the controller to be used is expected to be accessed using a LOCAL or NO_LOCK access mode. There are no changes required to the client code that performs the creation.
Although there is no need to class replace the controller to use multiple collections, one for each container, it may be wise to do so anyway, in particular if the controller to be used is expected to be accessed using a LOCAL or NO_LOCK access mode. In certain cases the relevant location object is available in the client code even if it is not passed on the creation signature. In other cases the input to the client code, typically the GUI (Graphical User Interface), must be changed to indicate the location object. Also the client code must be changed to use the new signature.
The present invention comprises also a method of developing a software system using an Object Oriented Technology and a method of locating software objects as described above.
Furthermore, the present invention comprises a data storage medium characterized in that said data storage medium is storing software objects using a method of locating these as described above.
If the controller has to be replaced to support more than one collection, the following steps have to be followed:
Create a controller class that is a subclass of the controller to be replaced.
Decide if the number of collections required is a fixed number.
If it is a fixed number of collections:
Decide the number of collections.
Create attributes for the collections.
Specify what location object to be used for creating the collection.
Create a scenario for determining the collection to use for new objects.
Create a scenario for finding an instance that is held by key. In its simplest form this could be checking collection by collection, but if there are some way one could come up with a rule on how to search. Potentially one could provide a get method that takes some form of xe2x80x9clocation objectxe2x80x9d, to determine which collection to look in firstly.
Create object interaction diagrams (OID) for the scenario.
If it is not a fixed number of collections:
Decide the key for the collection of collections. Consider your answer to the question of whether there are one or several of the attributes passed on creation of the new object. The key is probably the object or objects in a key that is used to decide on the container. Consider using the container object itself.
Create a scenario for determining the collection to use for new objects. On creation of a new element, if the collection does not exist, create a new empty collection.
Create a scenario for finding an instance that is held by key. In its simplest form this could be an iteration over the collections, but if there are some way one could come up with a rule on how to search. Potentially one could provide a get method that takes some form of xe2x80x9clocation objectxe2x80x9d, to determine which collection to look in firstly.
Create attributes for the map of collections.
Create object interaction diagrams (OID) for the scenario.
If the controller is Root/Aggregate and there is a rule for finding existing objects and consider if the aggregating behavior should search the collections meeting the rule first for the company hierarchy, before looking in the other collections. This improves performance.
If the controller has Shared/Sharing or Root/Aggregate behavior, validate that this still works as expected. It should in most cases without change.
The coding is performed according the following:
Generate the code from a so called xe2x80x9cRose modelxe2x80x9d.
Implement the code necessary based on the scenarios and the objects identity (OID).
Update the name configuration to have your new class replace the old one.